pp108 : Managing Application Packages in the Organization Space

Managing Application Packages in the Organization Space

This topic provides an overview on managing application packages that are deployed in the Organization space.

In Process Platform, you can deploy application packages into runtime in the following spaces:

  1. Shared space (formerly known as ISV space): This space includes all the platform packages and custom packages that are intended to be accessible across all the organizations.
  2. Organization space: This space is unique for an organization and the packages deployed in this space are accessible only to the users of that organization.

Deploying application packages into an organization space enables the administrators to deploy customized versions of an application in specific organizations. These packages will be accessible only to the users of that organization. This is useful especially in the scenarios where a Process Platform instance is used for deploying packages of different customers and also restrict the access of the application package only to few intended users. It also gives an additional advantage of managing the dependency on the Shared space; users can choose to continue with an older version of a package even when the package of similar version deployed into the Shared space is upgraded. 

Process Platform also allows you to have multiple organizations working on a single instance. It supports runtime multitenancy wherein all the artifacts are multitenant-aware at runtime. This ensures that each organization is independent of other organizations; changes made to artifacts in one organization will not impact other organizations that share the same artifacts. Refer to Multitenancy for a detailed information. 

Note:

  • You can deploy application packages of .cap format only in the Organization space. The application packages of the .isvp format cannot be deployed into Organization space.
  • As a System Administrator, you can deploy application packages to an Organization space from the System organization. You need to have Administrator role in the target organization.
  • As a Organization Administrator, you can deploy application packages to your organization space based on the authorization configured for that organization space by System Administrators
  • The packages which are marked as deployable at 'Organization' level are deployable to the Organization space.
  • Deployment of packages to System organization is not supported

Refer to Supported Deployment Spaces for information on configuring a package to be deployable at organization level.

Managing application packages across spaces

You can select a version of a package to deploy or upgrade and rollback during deployment. The following scenarios explain the various options of managing different versions of packages across the Shared and Organization spaces.

Viewing application packages deployed in the Organization space

While managing application packages across organizations, you might need to have an overview of the packages and their versions deployed in a specific organization. You might also need to view the list of organizations where a specific application package version is deployed. As an administrator, Process Platform enables you to have a complete picture of the application package deployment landscape and have a better control on the deployment or upgrade of dependent packages across the Shared and Organization spaces.
For instance, consider an application package A of version 1.0 is deployed in the Shared space and another application package B of version 1.0, that is dependent on the package A, is deployed in the Organization space. In this case, if application package A is ready to upgrade to version 2.0, it may have a significant impact on the dependent package B based on the usage of the application content and its change set. Before performing such upgrades, the following views enable the system administrators to see the impact of upgrade across organizations and take appropriate measures for the dependent packages.

Viewing Organization Summary
  1. Open Application Deployer. The deployment overview is displayed.
  2. Click the  Summary tab and click Organizations on the Deployment Overview section. 
  3. Select All or a set of organizations as required.
  4. Select one of the options below to filter the application packages:
    1. To view cluster status of all the packages, click the Show All option.
    2. To filter a set of packages, click  adjacent to the Show Selected option. A modal dialog with a list of packages is displayed.
  5. Click View, to view the details of the selected packages. A tabular view of the packages with the status details in the organization is displayed.
  6. For the node level deployment status of the package in a particular organization, click on the version or the status link.
    Each column in the grid, represents an available node in the cluster. Each cell element displays the version of the package deployed on that node.

Deploying application packages in organization space

  1. On  CUSP  >  My Applications, click  (Application Deployer ). The  Deployment Overview  page appears, displaying all the applications in the Applications List pane on the right.
  2. Click  Organization  in the Space section on the Deployment Overview panel.
  3. Click , select the required organizations from the Organization List dialog box that is displayed and click OK. The name of the organization being selected will be displayed in the output field. If multiple organizations are selected, the value in the output field will be displayed as Multiple Organizations.
    Note:
    • The Package Status details will be displayed only if you had selected single organization for deployment. The Applications List pane will display the packages related to that organization only.
    • The Package Status details will not be displayed if you had selected multiple organizations for deployment. The Application List panel is populated with the application packages which are deployable into an Organization Space.
  4. Right-click the required applications and select Deploy. The Application Deployer wizard appears, displaying the Selected Applications screen.
  5. Click Next to continue. The  Package Impact  wizard appears, displaying the list of actions that will be performed on the selected packages and their dependencies. 

    Based on the organization and the package selection, the deployment operation may change. The following table explains the possible deployment operation based on the package being selected and its current deployment status in an organization space. It is applicable for all the packages across all the organizations selected.

    Package being selected Current deployment status Operation
    Package A 2.0 Package A 1.0 is deployed Upgrade
    Package A 1.0 Package A 2.0 is deployed Rollback
    Package A 2.0 Package A 2.0 is deployed No Action. (The package will be skipped)
  6. Click Next to continue. The  Application Signature Verification Status  page is displayed. If the status of any of the selected application package appears to be tampered with or unsigned, follow the steps described here to continue with deployment.
  7. Click Next to continue. The  Impact Analysis  page is displayed. By default, the artifact information of the first package and the organization is displayed. To view the artifact impact of other packages in other organizations, select the required package and organization from the list.
    Note:  In case of a cluster setup, which has primary and secondary nodes, the impact gives an overview of the artifacts deployed on the primary node and the artifacts deployed on the secondary nodes.
  8. If you have selected to deploy an MDM model, you must do the following in the User Inputs page:
    1. Select the organization from the Select Organization drop-down list. Select the package in the Select Package To Configure Details.
      1. Select the proxy user and the MDM proxy user from the drop-down list that are required to communicate with other applications on Process Platform.
      2. You may select an existing MDM Publisher service group or configure a new one:
        1. Click to select an existing MDM Publisher service group.
        2. Click to configure a service group. The Hub Publisher field is selected by default. Refer to Fields for Configuring MDM Service Groups for information on the fields. 
          Note: The MDM Publisher and the MDM Service service groups that are associated with the MDM model must not be renamed after the model is deployed successfully.
      3. Click Next to continue.

        Configure service groups in all the organizations for a package. Ensure that the MDM Repository database is unique per organization for a package.

          Note:  If you are deploying an MDM model in a primary-distributed setup, it is adequate to deploy it in the primary computer alone. 
        Select the primary node alone in the screen displayed and click Next.

  9. Click   Next   to continue.  The  Applications Summary  page appears, displaying the actions that will be performed on the available nodes of the package for each organization selected.
  10. You can do the following in the  Applications Summary  page. 
    1. Select the Revert on failure option to revert the deployment action in case of failure.  
      Note:  If the application fails to install, the status of the application is displayed as Incomplete on the  Deployment Overview  page. Refer to Redeploy or undeploy an incompletely deployed application for information on completing the deployment.
    2. Specify the timeout value for the deployment in Timeout (in minutes). This specifies the time to be taken for the application deployment. The client will be timed out after this period.
  11. Click  Deploy  to complete the process. The deployment progress will be shown for each package and in each organization space.
    The applications are deployed in the organizations using Application Deployer .

Undeploying application packages in organization space

  1. On CUSP > My Applications , click   (Application Deployer). The Deployment Overview  page appears, displaying all the applications in the  Applications List  pane on the right.
  2. Click  Organization  in the Space section on the Deployment Overview panel.
  3. Click , select the required organizations from the Organization List dialog box that is displayed and click OK. The name of the organization being selected will be displayed in the output field. If multiple organizations are selected, the value in the output field will be displayed as 'Multiple Organizations'.

    Note:

    • The Package Status details will be displayed only if you had selected single organization for deployment. The Applications List pane will display the packages related to that organization only.
    • The Package Status details will not be displayed if you had selected multiple organizations for deployment. The Application List panel is populated with the application packages which are deployable into an Organization Space.
  4. Right-click the required applications and select Undeploy. The Application Deployer wizard appears, displaying the Selected Applications page and their dependent packages.
  5. Click Next to continue. The  Impact Analysis page is displayed. By default, the artifact information of the first package and the organization is displayed. To view the artifact impact of other packages in other organizations, select the required package and organization from the list. 
  6. Click Next to continue. The Applications Summary page appears, displaying the undeploy actions that will be performed on the available nodes of the package for each organization selected.
  7. Click Undeploy to complete the process. The undeployment progress will be shown for each package and in each organization space.

The applications are undeployed from the organizations using Application Deployer .  

Dependencies between packages across spaces

In a typical application development life cycle, multiple people will be working on multiple projects simultaneously. This mode of development will also enforce dependencies across the projects and the application packages being developed. In Process Platform, an application package can depend on multiple application packages. The package dependencies can also be deployed across different spaces (Shared and Organization). A package deployed in the Organization space can only depend on the set of packages deployed in both the current Organization space and the Shared space.

  • Packages deployed in the Shared space cannot depend on packages deployed in an Organization space.
  • Packages deployed in Organization A cannot depend on packages deployed in Organization B.
  • Packages deployed in the Shared space cannot be undeployed if there are any dependent packages in the Organization space.

Also, note that at any point of time, deployment is allowed in one space. You can either deploy to organization space or to shared space but not both at a time. This is applicable for dependent packages as well. Therefore, consider a scenario where a package A with version 1.0 is deployed in Shared space. Now the package A with version 2.0 is also uploaded. When a package B with version 1.0 which depends on Package A and if the package B is selected to be deployed to Organization X, the Package A will be it's dependent package and since version 2.0 is available, will be considered as upgrade. However, since the selected space is different (Organization, in this case), the Package A will not be upgraded to version 2.0

Dealing with application package versions

  1. You can deploy a version of an application package in multiple organizations. For example, an application package 'A' of version 1.0 can be deployed in multiple organizations.
  2. Application packages of different versions can also be deployed in different organizations. However, at any point of time, only one version of a package is allowed to be deployed in an Organization or Shared space.

All artifacts are not organization aware. If an application package is being deployed in organization space which contains an artifact that does not support the organization level deployment, the deployment action will fail with an appropriate error message. Refer to Runtime Behavioral Exceptions in the Organization Space for more information.